개요

다음으로는 설치된 실리움의 설정 정보와 통신 흐름을 조금 더 구체적으로 탐구하는 시간을 가진다.
조금 더 다양한 명령어로 상태 모니터링이 가능한데, 당장은 조금 미완된 구석이 있어 이후 보충하고자 한다.

실리움 탐색

기본적으로 실리움에 적용된 설정은 다음의 명령어로 확인할 수 있다.

cilium config view
kubectl get cm -n kube-system cilium-config -o json | jq

각 노드에 적용된 실리움의 설정을 상세하게 보고 싶을 땐 cilium-agent를 디버깅하면 된다.
에이전트에는 cilium-dbg라는 디버깅 툴이 내장되어 있어 이를 활용해 설정을 확인할 수 있다.

kubectl exec -n kube-system -c cilium-agent -it ds/cilium -- cilium-dbg config
kubectl exec -n kube-system -c cilium-agent -it ds/cilium -- cilium-dbg status --verbose

현재 kube-proxy 대체 모드가 활성화됐으며, 소켓 기반 로드밸런싱이 되고 있다는 정보도 확인할 수 있다.

노드 내 정보 확인

다음으로는 노드에 직접 들어가서 확인할 수 있는 정보를 본다.

ip -c addr
ip -c addr show cilium_net 
ip -c addr show cilium_host

ip -c addr show lxc_health

먼저 간단하게 각 인터페이스가 어떤 것을 뜻하는지 도식화하자면 이렇다.

각 인터페이스가 어디에 연결돼있는지는 몇가지 명령어를 조합하면 조금 더 확실하게 파악할 수 있다.

lsns -t net

일단 lxc로 시작하는 두 가지는 파드의 네트워크 네임스페이스에 연결되는 인터페이스이다.
lxc_health 는 별도의 네임스페이스로 지정되어 실리움 헬스체킹에 활용된다.
헬스체킹 유형에는 두 가지가 있는데 그 중 하나는 ping, 즉 ICMP 프로토콜을 이용해 이뤄진다.^[1]
헬스체킹에는 별도의 엔드포인트가 부여되는데 이 엔드포인트는 다음의 설정을 가지고 있다.

• endpoint id - 실리움 에이전트에 의해 노드 별로 고유한 값이 랜덤하게 할당된다.
• identity - 4로 고정된다.
• ip - 실리움 에이전틔에 의해 랜덤하게 할당된다.
• 가상 인터페이스 - 위에 보이는 lxc_health

이 정보는 아래의 명령어로 확인할 수 있다.

kubectl exec -it -n kube-system ds/cilium -c cilium-agent -- cilium-dbg endpoint list
kubectl exec -it -n kube-system ds/cilium -c cilium-agent -- cilium-dbg status --all-addresses

실제로 헬스체킹되고 있는 상태는 bpf에 기록된 테이블에서 흔적을 찾아볼 수 있다.

kubectl exec -it -n kube-system ds/cilium -c cilium-agent -- cilium bpf ct list global |  grep ICMP |head -n4
kubectl exec -it -n kube-system ds/cilium -c cilium-agent -- cilium bpf nat list | grep ICMP |head -n4

이밖에도 다양한 명령어들을 통해 여러 정보를 습득할 수 있다.

alias c1="kubectl exec -it -n kube-system ds/cilium -c cilium-agent -- cilium-dbg"

# 패킷 모니터링
c1 monitor
## 엔드포인트 특정
c1 monitor --related-to=<id>
## 드랍 이벤트
c1 monitor --type drop
## l7 층 트래픽 유형
c1 monitor -v --type l7


# ip 기반으로 라벨, 신원 확인
c1 ip list

# 신원 확인
c1 identity list
c1 identity get

# 로컬 bpf 정보 확인
c1 bpf fs show
## 파일시스템을 통해 현재 들어간 컨트롤러, 파일을 확인할 수 있다

# 로드밸런서 서비스 확인
c1 service list
c1 bpf lb list

# cgroup id 확인
c1 cgroups list

# 정책 확인
c1 bpf policy get --all -n

통신 확인

마지막으로 어떤 식으로 통신이 이뤄지는지 추적해본다.
이를 위해 먼저 간단하게 명령어 별칭을 지정해준다.

export CILIUMPOD0=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-ctr -o jsonpath='{.items[0].metadata.name}')
export CILIUMPOD1=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-w1  -o jsonpath='{.items[0].metadata.name}')
export CILIUMPOD2=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-w2  -o jsonpath='{.items[0].metadata.name}')
echo $CILIUMPOD0 $CILIUMPOD1 $CILIUMPOD2

# 단축키(alias) 지정
alias c0="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- cilium"
alias c1="kubectl exec -it $CILIUMPOD1 -n kube-system -c cilium-agent -- cilium"
alias c2="kubectl exec -it $CILIUMPOD2 -n kube-system -c cilium-agent -- cilium"

alias c0bpf="kubectl exec -it -n kube-system ds/cilium -c cilium-agent -- bpftool"
alias c0bpf="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- bpftool"
alias c1bpf="kubectl exec -it $CILIUMPOD1 -n kube-system -c cilium-agent -- bpftool"
alias c2bpf="kubectl exec -it $CILIUMPOD2 -n kube-system -c cilium-agent -- bpftool"

참고로 bpftool은 ebpf 프로그램의 상태나 정보를 관측하는데 활용되는 대표적인 툴이다.

파드 간 통신

조금 더 파면 전부 자동화시킬 수 있겠지만 아직 익숙하지 않아 일일히 확인하며 각 명령어를 수행했다.

# webpod 첫번째
WEBPOD1IP=10.245.1.148
# curl-pod에 연결된 네트워크 인터페이스
LXC=lxc520babe6914c
c1 map get cilium_ipcache | grep $WEBPOD1IP


c0bpf net show | grep $LXC 

webpod로 트래픽을 보낼 때 어떤 노드로 보내야할지에 대한 정보가 표시된다.

현재 curl pod에서 발생하는 트래픽에 대해 발동될 ebpf 프로그램이 무엇인지 확인한다.
cil_from_container, cil_to_container와 같은 bpf 프로그램은 /sys/fs/bpf에 담겨있다.

출력된 id를 기반으로 프로그램을 조금 더 파헤쳐본다.

c0bpf prog show id 1802

맵 id가 나오는데, 이걸 또 이용해 어떤 맵을 가지는지 확인할 수 있다.

이제 실제 통신 과정을 확인해보자.
curl-pod가 있는 ctr 노드, webpod가 있는 w1 노드에 각각 ngrep으로 http 트래픽을 추적한다.

ngrep -tW byline -d eth1 '' 'tcp port 80'

이 상태에서 요청을 날려본다.

kubectl exec -it curl-pod -- curl $WEBPOD1IP

먼저 ctr 노드에서는

파드에서 서비스로 향하는 통신 - 소켓 기반 로드밸런싱

마지막으로 볼 것은 파드에서 서비스로 향하는 통신이다.
위에서 잠시 봤듯 kube-proxy 대체 기능 탭에 Socket Based LoadBalancing도 활성화된 것을 볼 수 있었다.
이것 덕분에 서비스로 보내는 요청에 대해, 소켓 레벨 로드밸런싱이 잡혀 있어 특이한 현상을 목격할 수 있다.^[2]
기본적으로 파드에서 서비스로 트래픽을 보낸다면 다음의 방식으로 트래픽이 흘러간다.

• 파드의 요청이 노드의 네트워크 네임스페이스로 나간다.
• kube-proxy에 의해 iptables가 작성돼어 있어 서비스의 ip로 가는 트래픽은 백엔드 파드 ip로 이어진다.

그러나 소켓 기반 로드밸런싱은 파드에서 노드 네트워크 네임스페이스로 나가기 이전에 백엔드 파드 ip로 향하도록 트래픽의 경로가 설정된다.
원리는 프로세스에서 소켓 연결을 하기 위해 connect syscall을 호출할 때 바로 백엔드 파드 ip를 넣어서 소켓 구조체를 반환하기 때문이다.
결과적으로 파드의 요청 프로세스는 서비스 ip로 보내는 줄만 알고 동작하나 정작 보면 바로 백엔드 파드 ip로 트래픽을 보내게 되는 것이다.
이러한 방식에서는 iptables를 이용할 필요갸 없다.

요청을 보내는 파드에서 tcpdump를 걸어두면 이 기능을 명확하게 확인할 수 있다.

kubectl exec curl-pod -- tcpdump -enni any -q

webpod 서비스는 10.96.46.59 주소를 가지고 있는 것을 확인할 수 있다.

원래 이 요청은 파드에서 나갈 때만큼은 서비스 ip의 주소를 목적지로 두고 나가야만 한다.
그러나 막상 패킷 덤프 결과를 보면 10.245.1.148로 트래픽이 날아가는 것을 확인할 수 있다.

해당 주소는 webpod 파드 주소로, 트래픽이 인터페이스를 나갈 때 이미 파드의 ip를 목적지로 향한 것을 알 수 있다.

이후 주차에서 사용할 허블 모니터링 툴을 이용하면 소켓 로드밸런싱이 일어나는 상황을 더 명확하게 확인할 수 있다.^[3]
이 실습은 이후 주차에서 다시 해보는 것으로 한다.

마무리

소켓 기반 로드밸런싱은 주의할 점이 있다.
이스티오나 여타 네트워크 모니터링 툴 등은 최소한 파드에서 나가는 트래픽은 별도의 조작이 이뤄지지 않을 것이라는 가정하며 동작한다.
그래서 소켓 레벨에서 트래픽의 목적지 주소가 변환되어 버리면 정상적으로 트래픽 정책이나 설정이 적용되는 것이 보장되지 않는다.
만약 다른 네트워크 솔루션을 사용한다면 이점을 염두하고 파드 레벨에서 소켓 레벨 조작이 일어나지 않도록 설정을 추가할 필요가 있다.

이전 글, 다음 글

• 1W - 클러스터 세팅 및 cni 마이그레이션: 2
• 2W - 허블 기반 모니터링: 4

다른 글 보기

관련 문서

지식 문서, EXPLAIN

기타 문서

참고